The IP multimedia subsystem (IMS) is a specific domain in mobile communication networks such as in General Packet Radio Service (GPRS) and Universal Mobile Telecommunication Systems (UMTS) networks. IMS enables the centralized provision of multimedia and other services to users. IMS-based services may be used essentially independently of a particular access technique; for example, while normally the access will be based on a packet-based transport mechanism, a user may also access the IMS via a CS (Circuit Switched) domain of, e.g., a GSM network. Independent of the specific access chosen, a user has to register in IMS in order for a provision of IMS services. Registration and service provisioning to a specific user is controlled by a Serving Call State Control Function (S-CSCF) of the IMS.
Roaming scenarios as known for the provisioning of speech services, for example, are also relevant for the provisioning of IMS services. A user may attempt to register in its home IMS network via the IMS domain of a visited network. In this case, the user terminal sends its registration request to a Proxy CSCF (P-CSCF) of the visited network, which forwards the registration request to the user's home network. For this purpose, at least one Interrogating CSCF (I-CSCF) has to be available at the home IMS network, to which the P-CSCF sends the registration request. It is then the task of the I-CSCF to identify an appropriate S-CSCF of the home network and send the registration request thereto.
The prerequisite for such an IMS roaming scenario is that a roaming agreement is in place between the home network and the visited network which defines that and how a visiting user can access a desired service in its home network via the visited network. With regard to IMS services, today's roaming agreements often merely comprise a tunneling approach, e.g. because the visiting network does not have an IMS. This means that the visiting user traffic is tunneled from an SGSN (Serving GPRS Support Node) in the visited network to a GGSN (Gateway GPRS Support Node) in the home network. This solution may not assure a desired QoS (Quality of Service) for the user. Consider for example the case that a simple bearer for Best Effort QoS is provided in the visited network. This might not suffice for the service actually requested by the user from the home network, e.g. in case of a high bandwidth and/or low latency multimedia delivery session such as videotelephony.
The number of IMS domains increases and will most probably continue to increase in the future, including IMS networks with local and/or temporary coverage only which are enabled by cost-efficient “IMS in a box” solutions. In order to be able to flexibly provide multimedia services to the users it is a prerequisite that services can be provided with a desired quality to the IMS users and thus corresponding roaming agreements have to be in place. Currently, roaming agreements are normally set up manually. However, it appears unfeasible from a practical (business) perspective to manually manage the required numbers of roaming relationships in the future, not only in view of the generally increasing number of IMS domains, but in particular with regard to IMS domains which are only temporarily existing, for example for the duration of an exhibition, conference, cultural event, etc.
Moreover, it appears desirable to have the possibility to flexibly update an existing roaming agreement, for example in order to be able to flexibly react on short-term traffic peaks or temporary service offerings, which normally will not be achievable by manual administration of roaming agreements.
For these reasons, procedures for automatically establishing (and updating) roaming agreements between IMS networks are required. The 3GPP Technical Specifications TS 24.228 and TS 24.229 define IMS signalling flows, including signalling flows between IMS networks in case of roaming. However, in these specifications it is assumed that a roaming agreement is either in place or not, i.e. the procedures are based on manually established roaming agreements. The 3GPP Technical Report TR 22.971 describes a form of “automatic” roaming based on a central inter-network service point, which is provided to enable the establishment of roaming relations.
In the 3GPP TR 22.980, implementation examples for so-called Network Compositions are described. Such Compositions are based on a concept developed within the “Ambient Networks Project”, in which a generic network architecture has been developed, including generalized control functions and standardized reference points between two networks. The concepts include a generic automatic negotiation procedure performed between networks, see for example the Ambient Networks Deliverable D3-G.1 “Design of Composition Framework” of November 2006, available online on http://www.ambient-networks.org/deliverables.html. However, while generic scenarios for automated roaming agreement negotiations are discussed, no practically applicable solutions for roaming agreements between IMS networks are provided.
In fact, in order that automatic establishment procedures for roaming agreements between IMS network become feasible, various problems remain to be solved in detail. Herein, in particular the following problem is considered: In case of manually set up roaming agreements, when a roaming agreement expires or is terminated, this typically happens statically and therefore the agreement can only be cancelled in the same way, i.e. involving manual interaction and demanding a manual deletion of entries in the HSS. There is no mechanism existing which allows to manage user registrations in the home network in relation to the status of an automatically established roaming agreement. In particular, in case of an expiry or termination of automatically established (dynamic) roaming agreements, users in the visiting network need to be deregistered in the HSS of the home network. An automated mechanism is required in this respect, as, in view of the increasing volume of roaming agreements, manual termination and deregistration will not scale.